Skip to content

Conversation

@Shubham8287
Copy link
Contributor

@Shubham8287 Shubham8287 commented Nov 12, 2025

Description of Changes

A background task to cleanup unsubscribed views.
fixes #3587

API and ABI breaking changes

NA

Expected complexity level and risk

2

Testing

Added a test

Signed-off-by: Shubham Mishra <[email protected]>
@Shubham8287 Shubham8287 changed the title views cleanup Views: cleanup unsubscribed views Nov 12, 2025
@Shubham8287 Shubham8287 self-assigned this Nov 12, 2025
Signed-off-by: Shubham Mishra <[email protected]>
@bfops bfops added the release-any To be landed in any release window label Nov 17, 2025
@Shubham8287
Copy link
Contributor Author

Test is better modularised in this PR - #3670.

Copy link
Collaborator

@joshua-spacetime joshua-spacetime left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The approach makes sense. I just have a couple thoughts:

  1. I think we should be more conservative in how frequent we clean up views. I don't think our clean up intervals need to be on the order of seconds.

  2. Also we probably want to bound the length of time a cleanup job takes. If there are many old views, I think we'd rather clean them up in multiple jobs to avoid taking a tx lock for an extended period of time.

@Shubham8287
Copy link
Contributor Author

Shubham8287 commented Nov 20, 2025

  1. Also we probably want to bound the length of time a cleanup job takes. If there are many old views, I think we'd rather clean them up in multiple jobs to avoid taking a tx lock for an extended period of time.

Should it be limited by a hardcoded number (like 100 cleanups at a time) Or duration (atmost to take 5ms) or something else?

I feel limiting it to hardcoded number of views to cleanup can be a problem if continously more new views expires more than that number between job intervals.

@joshua-spacetime
Copy link
Collaborator

I agree, I think duration is the right metric. And we can even make that duration configurable later (not a requirement for this PR).

github-merge-queue bot pushed a commit that referenced this pull request Nov 20, 2025
# Description of Changes
Make View backing tables and related St tables not persistent.

1. Modifies `CommittedState` to hold set of ephemeral tables.
2. Update `TxData` to contain a subset of ephemeral tables which has
been modified in current transaction.

`do_durability` filter those table out before writting the transaction
to commitlog.

depends on: #3651
# API and ABI breaking changes
NA

# Expected complexity level and risk
2.5.

looks simple but changes comes in the hotpath, I ensured we don't do
unneccessary heap allocations but patch has the potential to regress
perfomance.


# Testing

- unit test.

---------

Signed-off-by: Shubham Mishra <[email protected]>
Co-authored-by: Mazdak Farrokhzad <[email protected]>
@Shubham8287 Shubham8287 added this pull request to the merge queue Nov 20, 2025
Merged via the queue into master with commit 6b43769 Nov 20, 2025
36 of 37 checks passed
@Shubham8287 Shubham8287 deleted the shub/clear-views branch November 21, 2025 09:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release-any To be landed in any release window

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Clear materialized view tables async

4 participants